Business Analyst Community & Resources | Modern Analyst

Three Audacious Goals for Business Analysts in 2013

Jarett Hailes — Wed, 02 Jan 2013 19:07:00 GMT

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals.

Merriam-Webster defines audacious as “intrepidly daring” and “marked by originality”. As the business analysis profession and Business Analyst community continue to mature, more organizations are seeing the value that professionally-executed business analysis can bring. Business Analysts have an opportunity to help organizational leaders achieve their vision for the future. Here are three audacious goals for 2013 to help Business Analysts capitalize on this opportunity.

1. Move Beyond Information Technology Solutions

Most Business Analysts are focused on the development of IT solutions to meet business needs. The ‘IT Business Analyst’ has been hailed as key cog in the overall IT delivery framework for organizations.

While information technology is one crucial supporting function every organization needs, it is not the only area where Business Analysts can deliver value. Technology is only effective if there people who know how to use it and processes that will ensure the overall business is able to perform tasks in an efficient and effective manner. Business Analysts need to ensure that all three of these aspects work together by identifying and assessing requirements for all components, not just the technology-related pieces.

Business Analysts can challenge the perception that their work solely fits into IT by demonstrating their ability to consider the process and people components during their prescribed activities. Go beyond writing system specifications and point out potential challenges that people will have with a complicated screen layout, or identify regulatory or policy issues that will impact certain functional requirements. Such actions will allow clients to see the need for a more holistic approach to solution development and can improve the high failure rates seen by projects that are ostensibly driven by IT. Even if you are working in a systems support role, you have the opportunity to present a more complete picture about proposed modifications that will allow everyone to realize how an application should be changed to meet the organization’s needs.

2. Master and Leverage Complementary Disciplines

As a Business Analyst you already rely on competencies and knowledge from other disciplines. Most business analysis knowledge areas use notions from areas such as systems analysis, project management and facilitation.

There are several disciplines that provide wonderful skills and techniques that Business Analysts can use to help accomplish their daily tasks more effectively. If you take the time to learn and master one or more of these disciplines, your value to your organization can increase exponentially. Not only do you improve your career options but you become a better Business Analyst by being able to deal with a greater breadth of problems.

Some of the disciplines that are worth mastering as a Business Analyst are:

· Change Management: understanding how people deal with change and how to help navigate organizations through change is a crucial set of skills in today’s environment. Business Analysts can leverage change management practices throughout their activities, most noticeably in stakeholder analysis, requirements management, requirements analysis and enterprise analysis.

· Mediation/Conflict Resolution: with change comes the possibility of interpersonal conflicts. People can disagree for a variety of rational and irrational reasons. Business Analysts are often at the forefront of such conflict while they attempt to define and manage requirements. Understanding how to assess a conflict’s root cause and having techniques to defuse volatile situations are crucial to help gain consensus and keep a project moving forward.

· Performance Measurement: Business Analysts can play an important role in reviewing existing solutions or working on the business case for change. Being able to define and implement relevant measures to evaluate individual solutions or an overall organization are key tools that are needed to help keep companies moving forward. Knowing how to leverage methodologies such as Lean and Six Sigma make doing these tasks that much easier.

3. Use Your Skills to Give Back

Many Business Analysts already volunteer their time to causes they believe in, but it may not be in a capacity that leverages their professional skills. Business Analysts can get a lot out of using their skills to give back to others, while at the same time helping their community. Not only is there the satisfaction of helping those in need, but an opportunity to learn how to take the experiences from such efforts and apply them in their organizations of employment. There are opportunities to help organizations who need Business Analysts as well as helping our fellow Business Analysts improve.

Here are some ideas on how to give back:

· Find a local non-profit or charity who could benefit from some business analysis but don’t have the in-house expertise or financial resources to perform the analysis.

· If you like to volunteer in developing countries, speak with the organization you work with to see if you can help them improve their operations or help them with a specific project that requires business analysis. We already have “Doctors without borders” and “Engineers without borders” – why not “Business Analysts without borders”?

· Pay it forward: mentor a less experienced Business Analyst so they can share their knowledge and expertise in the future with others.

· Start a community of practice with other BAs either inside or outside your organization to help improve everyone’s collective maturity and share ideas on how to perform BA activities better.

· Work with your local IIBA chapter to put on an event that will help the BA community grow.

What are your professional goals for 2013? Do you have any audacious goals?

What are the Quantitative Benefits of Business Analysis?

Howard Podeswa — Sat, 27 Nov 2010 08:21:00 GMT

At the end of my IIBA Webinar I tossed out a question to listeners: What are the quantitative benefits of business analysis?

It’s something I’ve been spending some time on. While there are many touted (and self-obvious) benefits of analysis , hard figures are hard to come by – and it’s hard figures that high-level executives want to see when we make the case for the profession. Fellow BAs have begun to take me up on the challenge and I have, at the same time, been meeting with CEO, CFOs, CIOs and others in upper-level management. So I thought it was time to throw out the question to the collective wisdom of the Modern Analyst community. What I’m looking for are measures that quantify either the benefits that have been derived from business analysis or the costs of doing it badly: metrics like the annual cost to projects attributable to a poor requirements analysis process relative to the annual project budget; estimated decrease in turnaround time due to improved analysis, and so on. I’m also looking for war stories – either horror stories of where things went wrong due to poor analysis or uplifting stories when things have gone well – with figures to back it all up where possible. Alternatively – if you have a source of stats on the cost benefits of good requirements that you think is helpful, please pass that one, too.

Readers are invited to post their contributions to this blog or, if confidentiality is required, to contact me directly at howardpodeswa@nobleinc.ca. Once I have a representative response, I’ll be summarizing and posting the results on this site.

(Attached jpg: Caption: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”. Description: “Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

Howard Podeswa of Noble Inc.

Blog Image: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”.

“Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

Dispatches from the WCBA Conference: Retrospectives

Adrian M. — Wed, 18 Nov 2009 18:51:00 GMT

Dispatches from the WCBA Conference: Retrospectives

“Slow Down to Speed Up: Retrospectives for Improving Product and Process” was the title of one of the workshops I attended during day two of the WCBA conference.

Ellen Gottesdiener, Founder and Principal Consultant, of EBG Consulting tackled the subject of “Retrospectives”.

It was a great presentation and included a number of topics including:

What are Retrospectives?

“Retrospective – a ritual in which the entire project community comes together: reviews the iteration/release/project story (something which just finished), harvests the collective wisdom of the teams, tells the truth without blame or judgment, identifies what to appreciate and improve, understands and forgives its failings, and relishes in its successes.”

In a nutshell, it’s our chance to look back in the rear view mirror and learn from what just took place. The insights gained from retrospectives become the basis for improvement, both immediate and longer term.

Careful using terms such as postmortem (are you assuming you project is dead?)…

In order for a retrospective session to provide value, it must address 5 key questions:

· What did we do well that we might forget if we don’t discuss it soon?

· What did we learn?

· What should we do different next time?

· What still puzzles and intrigues us?

· What needs more in depth discussion and analysis?

When should Retrospectives take place?

The traditional practice for doing retrospectives or postmortems (if your project is dead projects) is at the end of the project. The problem with this approach is that on projects with longer duration the value and benefit of the retrospective diminishes as it is far removed from when most of the project activities took place.

Alternately, retrospectives can be done sooner than the end. For projects which have a set rhythm (regular iterations, regular releases, etc.) a retrospective session can be done at after of each of the repeating phases.

Lastly, you should also consider an ad-hoc retrospective as a valuable tool when you get caught by surprise by a project challenge or other significant unplanned event in the life of the project.

Why Retrospectives?

As with everything else that we do, retrospective must provide value in order to be worth the time and energy. Ellen explored the value proposition of this tool.

In a nutshell, retrospectives are a great way to harvest the collective wisdom of the entire project team by giving everybody a chance to tell the story from their perspective and to discover things that happened on the project that you did not know about.

Retrospective is a great method of free adaptive learning:

· Immediacy – doing the retrospective as soon as possible ensures the recent experiences are sharp in the team’s memory,

· Relevance – the learning is relevant because the team has a common vested interest in the project/milestone/iteration/release what just completed,

· Self-Direction – most of us we don’t like to be told what to do ->retrospectives allows the individual contributors to identify and choose what they want to adapt and change going forward.

Retrospectives that Work

A retrospective is a great community participation-based tool which works because needed change is identified, proposed, and implemented by the project team and not simply shoved down their throats by some executive who is disconnected from the day to day realities of the project.

Successful retrospectives:

· Use data -> how many stories we implemented as opposed to the last iteration, how many test cases per story, how many defects per function point, etc.

· Acknowledge individual feelings -> Remember that feelings do count!

· Have a pre-defined structure –since everybody knows that it will take place, it provides the freedom to participants to identify and implement change without fear or guilt.

A good structure for your retrospective session looks like this:

1. Readying – set the stage

2. Past – gather data

3. Present – generate insights

4. Future – decide what to do

5. Retrospect – close the retrospective (retrospect the retrospective)

Retrospective = basis for change – it’s really a very cheap, yet effective, change management strategy

I want to be a Business Analyst… Raise me, mentor me, and set me free!

Adrian M. — Sun, 07 Jun 2009 22:05:00 GMT

“Once upon a time, young people learned a trade through years of apprenticeship.”

Have you noticed an interesting dilemma faced by those wanting to enter the business analysis profession?

There don’t seem to be any “Junior Business Analyst” jobs. Most hiring organizations are looking for practitioners with prior business analysis experience.

Imagine wanting to begin a career as a driver and being told “You can’t drive the car until you know how to drive a car.”

And when you ask for advice on how to learn to drive a car you get answers such as:

“Here’s a list of good books about driving cars.”
“Talk to other drivers about their experience and how they got started.”
“Try first a related career such as car washing, car repair, etc.”
“Subscriber to Car and Driver magazine.”
Etc.

Sounds silly?

Well –that seems to be how we treat newcomers to our profession:

Managers want to hire the experienced Business Analysts for their projects but they don’t seem to want to grow BAs, and
Experienced practitioners want to work with and learn from other experienced BAs but they don’t want mentor junior ones.

Is business analysis a really a profession? Are we there yet?

I’m not so sure!

In most mature professions you will find that, in addition to the educational requirements which may exist, there is always a “practical” component to the path to getting started as a newbie:

Carpenters, auto mechanics, and plumbers have apprentices who are taught the trade.

Medical school graduates go through lengthy residency and fellowship programs where they gain real experience.

Law enforcement academy graduates are generally assigned to a training officer with whom they will spend months, if not years, on the street learning the realities of the profession.

If you want to learn to drive a car you are allowed to get behind the wheel and learn to drive even before you master the skill enough to pass the driver’s test.

That’s what we need in our profession!

We need managers, practitioners, visionaries, and leaders who are willing to hire newbies and help them start their careers as business analysts.

If you’re a newbie I bet you would love to find an organization who is willing to hire you right out of school/training, get you started as a business analyst, mentor you, and the launch you into a successful business analysis career! Wouldn’t you?

Helpful resources:
In this month’s issue of the Modern Analyst eJournal, you’ll find some great thought leadership on the value of and establishing Business Analysis Communities of Practice (BA COP) or Business Analysis Centers of Excellence (BA COE) which can act as the starting point of BA apprenticeship and mentoring programs.

Also in this issue you’ll find insightful articles on the Business Analyst Career Progression and the Potholes of Office Politics that new BAs may be faced with.

And in the spirit of providing you with a solid technical background, we continue our SOA series with an introduction of More Confusing SOA Terms.

- Adrian

Adrian Marchis
Editor, ModernAnalyst.com

Talking “Cloud” with Rajen Sheth — Inventor of Google Apps

Barton George — Wed, 11 Mar 2009 00:41:00 GMT

Cloud computing is one of the largest forces in IT in 2009. With the deeping of the global economic crisis it has only gathered more momentum.

In the beginning of the year I attended Cloud Connect in Mountain View to learn more about what was happening in this space and what the key players were thinking. The conference kicked off with an “Evening in the Cloud.” At this opening event, representatives from Google, Amazon Web Services, and Force.com tried to convince three heads of IT as to why they should move all their IT to the cloud. (Not sure who convinced whom, but it was an interesting debate nonetheless )

Representing Google was Ragen Sheth, its lead Product Manager and the person credited with inventing Google Apps. After he finished speaking I was able to grab a few minutes with Ragen to learn more about what Google’s been doing in the Cloud. Check it out.

Take a listen:

>> My talk with Rajen (9:47): Listen (mp3) Listen (ogg)

Rajen Sheth of Google Apps.

Some of the Topics we tackle:

How Google Apps is Google’s platform for businesses to run applications in the cloud.
Google App Suite is all about bringing the cool things Google has created on the consumer side and presenting it to the businesses.
Gmail opened up a whole new model for people to build web-based applications by bringing in AJAX.
Over the last 3-4 years a lot of really advanced apps have been built in the browser that utilize the unique leverage points of the cloud.
CIO’s have switched from “no way,” to talking feature sets when the subject of the cloud is brought up.
What will we see in 09 in the cloud? (The recession should help to drive adoption.)
Is Rajen seeing more cloud-interest from big or small companies?
When will we hit the Cloud tipping point?

Barton George
Sr. Director, Business Development, Blueprint process mapping tool
Lombardi Software

Talking with the President of Dell Americas about Cloud Computing and the Economy

Barton George — Tue, 13 Jan 2009 13:05:00 GMT

When I attended the RackSpace Customer event back at the end of September I was impressed with the talk that Paul Bell of Dell gave (Paul reports to CEO Michael Dell and is responsible for all business operations for Dell in North and South America). [Note: in the re-org that was announced at the the end of the year at Dell, starting next month Paul will now be in charge of the group that focuses on government, education, health care and the environment]

Dell and the Cloud(s) (sources: my hand + the football Dell gave out at the conference + Friday’s sunset)

In his keynote Paul talked about Cloud Computing and the challenges the economy was presenting Dell and its customers. I caught Paul after his talk and asked if I could tape a podcast with him. He graciously agreed and here’s the result that I recorded at the end of last year.

Take a listen:

>> My talk with Paul (11:59): Listen (mp3) Listen (ogg)

Some of the Topics we tackle:

The key Cloud characteristics: Speed to deployment and ease of turning on/off
The need to separate the “real” from the fictitious when it comes to the Cloud
The interest Paul is seeing in the Cloud from smaller companies
Two of the biggest ways Dells plays in the cloud 1) supplier of infrastructure 2) deliverer of IT as a service
How on one hand the tough economy is driving interest in utilizing the cloud while at the same time it is causing a slow down in the sales of cloud infrastructure
The economy (starts ~7:30): Looking back at what happened in 2001 and trying to gain insight
How the economic malaise that hit North America has finally caught up with South America
How Dell is planning to help customers during these tough times.

Barton George
Sr. Director, Business Development, Blueprint process mapping tool
Lombardi Software

5 Traits of Successful Projects

Adrian M. — Mon, 11 Jun 2007 01:30:00 GMT

Michael Vinje, an I.T. and software engineering specialist with more than two decades experience, has written an article on 5 Traits of a Successful project.

Anyone in charge of business analysts or systems analysts can benefit from understanding and analyzing these traits. Here is a rather quick summary:

1. Balance demand with capacity. Simply put: know your available capacity, estimate carefully, and do not over commit.

2. Dedicate resources the team can count on day in and day out. That is, do not allocate new tasks to resources already allocated. Also - make sure that you allocate the right type of resource (don't ask the SME to step into the role of business analyst).

3. Include skilled business analysts on the implementation team. Business and systems analysts must be are at the core of every IT project. The problems, needs, and requirements of the business must be clearly understood in order to succeed in any information technology project.

4. Rely on project managers that exemplify mature professionalism. Great execution management and leadership skills are a must for those in charge of the project.

5. Make fact-based decisions. Succesful IT teams rely on timely and accurate facts in order to respond quickly and appropriately to changing circumstances.

For full article, please see link to Baseline magazine:

5 Traits of a Successful Project